Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use bytes to represent memo text #259

Merged
merged 13 commits into from
Dec 13, 2019
Merged

Conversation

tamirms
Copy link
Contributor

@tamirms tamirms commented Dec 9, 2019

Fixes #257

The Java SDK assumes that all memo texts must be valid UTF 8 strings. However, that assumption is not valid. It turns out that any sequence of bytes is allowed to appear in the memo field (see stellar/go#2022 ).

Therefore, the correct representation for the memo field is a byte array.

Copy link

@ire-and-curses ire-and-curses left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a Java expert, but this looks solid to me.

CHANGELOG.md Outdated
@@ -2,6 +2,10 @@

As this project is pre 1.0, breaking changes may happen for minor version bumps. A breaking change will get clearly notified in this log.

## 0.12.0

* Represent memo text contents as bytes because a memo text may not be valid UTF-8 string.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's link to the issue (#257) from the changelog

src/main/java/org/stellar/sdk/MemoText.java Outdated Show resolved Hide resolved
tamirms and others added 2 commits December 9, 2019 22:49
Co-Authored-By: Eric Saunders <ire-and-curses@users.noreply.github.com>
Copy link
Contributor

@leighmcculloch leighmcculloch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, one question below.

@@ -335,7 +335,7 @@ union Memo switch (MemoType type)
case MEMO_NONE:
void;
case MEMO_TEXT:
string text<28>;
opaque text<28>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we keep the source of truth for our .x files? Does this get updated there also so that all other SDKs also get updated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they are kept here https://github.com/stellar/stellar-core/tree/master/src/xdr

I'm waiting for confirmation in stellar/go#2022 that we're going to change the type of the memo text field. Once we have confirmation we'll need to update the .x files in stellar core and in the go monorepo

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Files in xdr should be exactly the same as in stellar-core repo, we shouldn't change them here nor autogenerated files in: src/test/java/org/stellar/sdk/xdr.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bartekn

I'm waiting for confirmation in stellar/go#2022 that we're going to change the type of the memo text field. Once we have confirmation we'll need to update the .x files in stellar core and in the go monorepo

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is merged after the changes are in stellar-core master then 👍.

Copy link
Contributor

@bartekn bartekn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should merge it in the current form (we shouldn't change xdr files). This will be a problem when the files change in stellar-core repo (need to manually find the changes we added and apply them on top of core changes).

Maybe a solution could be adding a new file in xdr with Transaction class that parses memo correctly? This isn't ideal too but at least won't break when xdr is updated/regenerated.

@@ -335,7 +335,7 @@ union Memo switch (MemoType type)
case MEMO_NONE:
void;
case MEMO_TEXT:
string text<28>;
opaque text<28>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Files in xdr should be exactly the same as in stellar-core repo, we shouldn't change them here nor autogenerated files in: src/test/java/org/stellar/sdk/xdr.

@tamirms
Copy link
Contributor Author

tamirms commented Dec 10, 2019

David wasn't in favor of changing the type of the memo field, stellar/go#2022 (comment) . So I was left with no choice except for changing the implementation of how XDR strings were represented in the Java code generator: stellar/xdrgen#48

I have removed the changes to xdr/Stellar-transaction.x and regenerated the java classes using the version of xdrgen from my pull request ( stellar/xdrgen#48 ).

Please review stellar/xdrgen#48 first and then review this PR


import static com.google.common.base.Preconditions.checkNotNull;

/**
* Represents MEMO_TEXT.
*/
public class MemoText extends Memo {
private String text;
private byte[] text;
Copy link
Contributor

@leighmcculloch leighmcculloch Dec 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If text was an XdrString then we'd keep the UTF-8 conversion knowledge in one place, in the XdrString class. Right now that knowledge is spread out across XdrString and line 19 of this class, and any other class like MemoText that follows this pattern in the future.


if (new XdrString(this.name).getBytes().length > 64) {
throw new IllegalArgumentException("name cannot exceed 64 bytes");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change seems to be unrelated to the rest of this change. The rest of this change is specifically about memo text, but this change is to do with manage data operations. It seems out of scope and like it belongs in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I separated this change in a new PR it would depend on this branch because it requires XdrString. Lets keep both changes in the same PR for now. It shouldn't be too burdensome to review the extra changes

Copy link
Contributor

@bartekn bartekn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Memo check doesn't take into account ASCII encoding
4 participants